Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000092_owner-urn-ietf _Sat Mar 29 03:39:28 1997.msg

Internet Message Format | 1997-04-01 | 6KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id DAA10760
    for urn-ietf-out; Sat, 29 Mar 1997 03:39:28 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id DAA10755
    for <[e-mail]>; Sat, 29 Mar 1997 03:39:22 -0500 (EST)
Received: from beach.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA21467  (mail destined for [e-mail]); Sat, 29 Mar 97 03:39:21 -0500
Received: from beach.w3.org (beach.w3.org [207.8.37.250])
          by beach.w3.org (8.8.4/8.8.4) with SMTP
      id CAA16611; Sat, 29 Mar 1997 02:39:16 -0600
Message-Id: <[e-mail]>
Date: Sat, 29 Mar 1997 02:39:15 -0600
From: Dan Connolly <[e-mail]>
Organization: World Wide Web Consortium
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i586)
Mime-Version: 1.0
To: "Ron Daniel, Jr." <[e-mail]>
Cc: [e-mail]
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Dan Connolly <[e-mail]>
Errors-To: [e-mail]

Ron Daniel, Jr. wrote:
> At 04:06 PM 3/28/97 -0600, Dan Connolly wrote:
> >there seem to be
> >five sorts of things: names (N), locations (L), identifers (I),
> >resource instances (R) and URCs (C). It seems like there are only
> >finitely many interesting permutations.

Forget I said this. My argument doesn't even convince me any more.

> >If the list is extensible, it's extremely important to
> >specify what to do when you find an unknown operation and in
> >general, how new operations get deployed.

> (We may need to mandate that clients MUST NOT try to deal with unknown
> services, it was probably an unspoken assumption of mine).

Yes: write it down.

> >Yes, there are very useful _extrinsic_ distinctions between names
> >and addresses: external to the identifier, there might be
> >information that suggests it can be resolved or not, etc.

> OK, here I think we can agree. I don't see a lot of useful difference
> between L2L and N2L, so the operations of I2L, I2N, I2C, I2R (and their
> plural forms) may be sufficient. We can also have I2I, I2Is for when
> we don't need to maintain the distinction on the output.

I hope I can convince you that the "locator-ness" or an
one identifier (L) or the "name-ness" of another identifier (N)
isn't a property of the identifiers themselves, but rather a
relationship between them. If a service says N2L(N) = L, then
it's claiming that "L is a locator for N," not that L is
a locator in all contexts. L might also be a name with respect to
some other identifier L2 in another context.

Now... how to do that... I think I can only appeal to
design aesthetics, e.g. minimalism.

This leads to my criticism of L2L and N2N: what is it
that I learn about l1 with respect to l2
when a service says L2L(l1) = l2 that I would not learn
from I2I(l1) = l2?

> >RFC1630 is informational, not standards track. I suggest you
> >cite either the url syntax draft, or RFC1808, which I expect
> >will be updated/replaced by the ultimate url syntax draft.
>
> The problem is that RFC 1630 sets the model of URIs being the
> superset of URNs and URLs. The other documents you specify
> standardize URLs. I am unaware of a standards-track URI
> specification.

Ironic, no? I hope and expect that the URL syntax document
and the URN syntax document will be merged into a URI
syntax document.


> You really mean that there's
> >no relationship whatsoever between the N2L and the L2N operations?
>
> None that I wish to specify.
>
> ... I would be more inclined to warn client implementors that
> they should not assume it.

If that's your intent, I think you need to be explicit. The
names suggest that they're inverses.


> > It seems clear to me that if n is a URN
> >and l is a URL, then you can be certain that I2I(n) won't
> >return l and vice versa.
>
> That is not at all clear to me. In fact, the converse is what seems
> clear to me. If we say "map this I to another I", and we say that
> Ns and Ls are both instances of I, then we should expect either as
> a result.

You're right. I don't know what I was thinking.


> >> >> 4.10 I2I (URI to URI):
> [Dan states he thinks it is unneeded and wants to...]
> >try yet another argument:
> >
> >Suppose we had relations:
> >       N2N <: URN x URN
> >and
> >       L2L <: URL x URL
> >
> >If the intersection of URNs and URLs is empty (fair assumption?)
> >then N2N and L2L don't intersect. So one relation I2I that
> >is the union of L2L and N2N holds all the information from
> >both relations without creating any ambiguity.
>
> OK, here's the gap in our models. You seem to assume that URNs
> and URLs are partitioned to such an extent that providing a URN
> (or URL) as an input to I2I automatically restricts the output of
> the operation to the input type. I don't.

Aha... yes, that argument is garbage: it assumes an overly
narrow notion of I2I.

But I do think that only one equivalence relation is needed,
not three. I think I made a better argument above.

--
Dan Connolly, W3C Architecture Domain Lead
<[e-mail]> [phone]
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21